* Add options for `expectedInputLanguages`, `expectedContextLanguages`, and `outputLanguage`. The former two are used for downloading additional material and early errors if the web developer's required input/context languages cannot be supported by the browser. The latter gives clarity about what to do given mixed-language inputs.

* Remove the `capabilities()` method and the accompanying `AI*Capabilities` classes. The reasoning is as follows:

  Those classes had three APIs: `available`, `createOptionsAvailable()`, and `languageAvailable()`. `languageAvailable()` wasn't clear if it was talking about input, context, or output languages. Now that we have explicit options for those three, we could fold language availability testing into `createOptionsAvailable()`. But then, we can note that the `available` property is kind of useless, as just knowing that some possible combination of options/languages is supported is not helpful for any known use case. So, the only real functionality we care about is testing whether a given set of options to `create()` is supported.
  
  This was previously done via `(await ai.apiName.capabilities()).createOptionsAvailable()`. We instead expose it via `await ai.apiName.availability()`. This name is a bit clearer, and this design also avoids the complexity where we have to retrieve all the availability information for every combination of options during the call to `capabilities()`, for later sync access. Now we can just retrieve the relevant information during the call to `availability()`.

This was previously discussed in webmachinelearning/prompt-api#29; see especially webmachinelearning/prompt-api#29 (comment). Closes #16.

See also webmachinelearning/prompt-api#69 and webmachinelearning/translation-api#31.

…tector

Add an `expectedInputLanguages` option to language detector creation API. This allows the browser to download relevant material if necessary, or fail-fast if a language the web developer needs to support is not available.

Then, remove the `capabilities()` methods and the accompanying `AI*Capabilities` classes.

* For translator, the only useful capabilities API was `(await ai.translator.capabilities()).languagePairAvailable()`. We simplify this to `await ai.translator.availability()`. This design also avoids the complexity where we have to retrieve all the availability information for every combination of options during the call to `capabilities()`, for later sync access. Now we can just retrieve the relevant information during the call to `availability()`.

  Also, by unifying on using the same options for `create()` and `availability()`, we fix #24.

* For language detector, the capabilities supplied both `(await ai.languageDetector.capabilities()).available` and `(await ai.languageDetector.capabilities()).languageAvailable()`. We simplify this into `await ai.languageDetector.availability()`, which can either take no arguments (emulating `available`) or take the same `{ expectedInputLanguages }` argument as `create()` (emulating `languageAvailable()`).

See also webmachinelearning/writing-assistance-apis#22 and webmachinelearning/prompt-api#69.